this is great, was just browsing the docs and surprised it wasn't there

Another breaking pattern is when you reference a variable declaration inside a callback that was declared after the callback. This can happen accidentally when writing an especially complex component or hook. That callback won't be memoized by the compiler.

Would you consider this a common scenario?
https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAQgIYAmAFAJRHAA6xRchYORhAwgDZ5wBrIgF4itEQD56TIrJZsIPBADoeEAOZU0ECDRlEAvvv2tM7IgG1tEADREwCHADEdAXRFEoDgMo4yOBCoABj1MfRhHWGIAHgo8ADdOTF5+AWFgbj5BAwlgawNogHo4+IkmIzDMDGx8QiIAcR1qOkZmU3MrHTsHZzcPLwRff0CQkzYOTNSPcWEpVrl5M0UVNU1rUNkK8MiYGJKklMF0yezc-KKSsswDEAMgA

Yeah this is a fun case. Note that you can't memoize such callbacks yourself — adding a useCallback() in the "Bad" example in your playground link would be a TDZ violation when you added the dep on foo:

function Bad() {
  const onClick = useCallback(() => {
    console.log(foo)
  }, [foo /* TDZ violation */ ]);
  
  const [foo, setFoo] = useState(0)

  return <div onClick={onClick}>{foo}</div>
}

We can look into adding linting against this pattern to suggest moving the callback. Note that the compiler will already reject this code if you try to manually memoize it, because the dependency changes later.

Would you consider this a common scenario?

Since this pattern doesn't work with manual memoization, this pattern is most likely in code that isn't memoized already. Definitely worth adding validation to help identify opportunities in such code to memoize more.

❓ Question:

It may not belong to the "incremental adoption" section, but I wonder if it's worth answering the following question in the adoption plan or somewhere else:

There is a recurring question regarding the best practice for handling existing manual memoization APIs (useMemo, useCallback, memo) in a codebase after the React Compiler has been enabled. This uncertainty is common in discussions about adopting the compiler for large, legacy applications.

To address this, we could add a section to the official documentation, that answers the following:

FAQ: What is the recommended strategy for useMemo, useCallback, and memo in a large and legacy codebase after enabling the React Compiler?

Once the compiler is active, should teams begin a gradual process of removing these manual memoizations?
Our working assumption is that this is the intended outcome, as it aligns with the core purpose of the compiler.

Providing clear, official guidance on this topic will significantly reduce community uncertainty and help teams establish a consistent and effective adoption plan.

Added: https://react-dev-git-pr7868-fbopensource.vercel.app/learn/react-compiler/introduction#what-should-i-do-about-usememo-usecallback-and-reactmemo

❓ Question:

Is the use of react-compiler-healthcheck recommended at all?

That package isn't being actively maintained right now so I'm hesitant to document it. You can run the eslint rule as an alternative to get the same information on which files have violations that were detected.